coverage: 75.754% (+0.09%) from 75.661% when pulling 6d61287 on 0x221A:master into 625ca2e on 99designs:master.

Thanks! I appreciate this. Looking forward to more good work from you in the future!

no ... I think this is bug....

uuid is value type , like int.
default value is zero value ( uuid.Nil), in GraphQL is UUID!
nil ('null") is *uuid.UUID in Graphql is UUID. ( no !)

so this is bug!

@StevenACoffman @0x221A

@it512 Yeah, but I think nobody checking for zero value uuid. It's the same as time.Time that returns null instead of zero value time.

time.Time is struct , not a point, can not set to null!

*time.Time can set to nil !

time.Time is not *time.Time

For me, it still doesn't make sense to return zero value uuid. And you are right time.Time is struct but the marshaller still checking if it was zero time or not and still returns null if it was zero value time. If you dive into the generated code you will see it.

From what I see returning a zero value uuid is a bug unless you expected that and mostly no one expected the value 00000000-0000-0000-0000-000000000000 will return from the server instead of null.

There's always a problem translating between Go's "useful zero values" concept and GraphQL consumed by other languages.

• The zero value in Go of an int is 0. gqlgen returns this in GraphQL as 0.
• The zero value in Go of a time.Time is January 1, year 1, 00:00:00 UTC. gqlgen returns this in GraphQL as 'Null`.
• The zero value in Go of a pointer to either of those types is nil. For nil pointers, gqlgen returns in GraphQL's Null.

You cannot assign a time.Time to nil in Go:

	var myTime time.Time
	myTime = nil // error: cannot use nil as time.Time value in assignment

You also cannot assign a uuid.UUID to nil in Go:

	var myUUID uuid.UUID
	myUUID = nil // error:  cannot use nil as uuid.UUID value in assignment

When a JavaScript client makes a GraphQL call using the GraphQL Basic scalar types of String, Int, Float, Boolean, and ID, we expect the response to be useful values. I think that an int value of 0 is actually quite likely to be useful, both in Go and in GraphQL.

This PR made it impossible for gqlgen to respond with the valid, but unlikely to be useful, UUID value of 00000000-0000-0000-0000-000000000000. This seems equivalent tow how it is impossible for gqlgen to respond with a valid, but unlikely to be useful, time of January 1, year 1, 00:00:00 UTC.

Can you explain how or where 00000000-0000-0000-0000-000000000000 in GraphQL would be a useful value rather than Null?

@a8m @giautm @x80486 I would appreciate your opinion on whether this PR should be reverted or not.

This is correct. Null values in GraphQL are represented by the keyword null. Consequently, 00000000-0000-0000-0000-000000000000 is only meaningful in the Go world, but when the GraphQL response is built, null is needed (as expected), rather than an invalid UUID to signify null.

Bottom line, in GraphQL, null is semantically correct — it represents the lack of a value. 00000000-0000-0000-0000-000000000000 does not.

I think we can assume that 00000000-0000-0000-0000-000000000000 should return null by taking a look at how google/uuid handles NULL value from the database.

According to RFC 4122 Nil UUID is a valid UUID

https://datatracker.ietf.org/doc/html/rfc4122#section-4.1.7

It can usually be used as a placeholder in many scenarios, such as default values ​​of fields in databases, etc.

If Nil uuid == null, the Nil uuid field will return nil. . . this will be a disaster

If the UUID can be null, use a pointer type.

In graphql, you can use UUID( no !)

@0x221A @StevenACoffman @a8m

-------------- Chinese version

根据 RFC 4122 Nil UUID 本就是一种有效的UUID

https://datatracker.ietf.org/doc/html/rfc4122#section-4.1.7

通常在很多场景下都可以作为占位符使用，例如数据库中字段默认值等

如果 Nil uuid == null， Nil uuid 字段将返回 nil 。。。 这将是一个灾难

如果UUID 可以为空，请使用指针类型。

在graphql 中，你可以使用 UUID,没有！

code in goole.uuid

https://github.com/google/uuid/blob/v1.3.1/sql.go#L15

I added some comments

// Scan implements sql.Scanner so UUIDs can be read from databases transparently.
// Currently, database types that map to string and []byte are supported. Please
// consult database-specific driver documentation for matching types.
func (uuid *UUID) Scan(src interface{}) error {
	switch src := src.(type) {
	case nil:     // case 1 if field is null such as varchar(36) null ...
		return nil // *UUID = nil (golang nil)

	case string:
		// if an empty UUID comes from a table, we return a null UUID
		if src == "" {
			return nil // case 2 empty string if field type is string and value is ""(empty string).  return uuid is nil (golang nil)
		}

		// see Parse for required string format
		u, err := Parse(src) // case 3 field has value if src is Nil uuid (128 bit 0) , uuid = Nil UUID, /////  ** #2794 return golang nil BUG!!! **
		if err != nil {
			return fmt.Errorf("Scan: %v", err)
		}

		*uuid = u

	case []byte:
		// if an empty UUID comes from a table, we return a null UUID
		if len(src) == 0 {
			return nil
		}

		// assumes a simple slice of bytes if 16 bytes
		// otherwise attempts to parse
		if len(src) != 16 {
			return uuid.Scan(string(src))
		}
		copy((*uuid)[:], src)

	default:
		return fmt.Errorf("Scan: unable to scan type %T into UUID", src)
	}

	return nil
}

@0x221A @StevenACoffman

I think returning null first is the best way unless the user knows what they're dealing with. If that is the case use custom mapping.

And for me returning a zero value uuid without a clue will be a disaster more than null.

If I want to return Nil UUID how can I do it? no way in #2794 ！！！

In fact, any language distinguishes between zero values ​​and null values. but golang has made clear regulations on this

such as java， int and Integer
in java int called native type， default is 0， Integer called wapper type （Object type） default is null （java has no pointer）

in database if using int , null int field was return 0 (int default value), return null if using Integer

UUID in gqlgen is usedef type，Implemented according to RFC4122， base on google.uuid
it has zero value (Nil), in rfc 4122 defined Nil type UUID， google.uuid implement it

I think returning null according to usage, UUID! return zero value, UUID (no !) is *UUID default return nil (golang nil)

@StevenACoffman I'll leave this to you because it can go both ways. Because the implementation of json.Unmarshaler treats both null and zero value uuid the same way. And I found that google/uuid has a NullUUID type that can handle both ways. But I think it's not convenient to use it.

The behavior of json.Unmarshaler depends on the type. If it is a pointer type, null will be used. In other cases, zero value will be used.

Yes, that is the default. But for the NullUUID type, it has an additional Valid field that indicates whether to use a null or zero value...

For valid uuid NullUUID returns the correct UUID (valid is true), Nil (zero uuid) is valid, so the return is still Nil

NullUUID should only be used in ambiguous scenarios, or as a simple tool

graphql has a definition for nullability, use (!)

If available, please use UUID (no!)